Hei Marko, On Sat, Nov 26, 2011 at 11:41:56PM +0200, Marko Mäkelä wrote: > On Sat, Nov 26, 2011 at 08:27:41PM +0100, Gábor Lénárt wrote: > >"Extensions" are only remainments of the ancient CP/M systems, > >Unix does not have this notion > > Sorry, I could not resist the off-topic. > > As far as I understand, CP/M copied the file name conventions > (except subdirectories and file versions) from Digital VAX/VMS, > which was supposed to replace the archaic *nix systems. If OpenVMS > did not die in the hands of HP yet, theoretically it could still > win. :-) BTW, VMS distinguished binary and ASCII files, too. AFAIR, > CP/M does not really distinguish them, but it does not store exact > file lengths either. You will only know how many blocks the file is, > not how many bytes. Well, maybe. It was my idea that this is from CP/M as many stupidity came from there (ok, sorry for the word, not so stupid for CP/M, just for current technology it is), like driver letters, it's quite laughable that Windows etc systems have it even know, but no wonder, DOS seems to be a mixture of CP/M (like: PSP, FCB based file functions, etc), and UNIX (directories, file handle based functions, named device nodes) "inventions". As far as I know (I am not so a windows user) MS admitted finally that drive letters should be killed, and NTFS already knows about "reparse points" which is similar to the UNIX "mount" solution. But not to be so off-topic: I have some experience on DOS programming as I developed my own DOS for my own emulator some years ago called "DOSRUN" (well, not it has not so much reason to use, as DOSBOX is far more superior), so I had to meet with many CP/M notions, but sometime with UNIX ones (like the direct copy of dup() and dup2() syscalls, /dev/NODE functions which is still present in DOS to use though the usual way is to use CON and not /dev/CON ... /=\ switchable etc). However my knowledge on CP/M is only "I read this about it too"-kind at the best. > > I guess it would be somewhat funny if you ported the sound to > Commodore 128 CP/M, or maybe even the Commodore 64 CP/M. The latter Not so unrealistic btw, since I am interested in Enterprise-128 as well, which is a Z80 based computer, and also the CP/M cartridge (or the C128's built-in) uses Z80, even if CP/M was originally written for 8080 if I am correct (and Z80 is backwards compatible). Now my headache is caused by the lack of decent Z80 assembler: I am so used to work with cc65's assembler (ca65), I like it as a modern toolset with separated linker, quite complex linking configurations, macros, etc etc. But ca65 (cc65's assembler) does not do Z80 ... I don't want to use another assembler since I like ca65 so much, so I started to write a "pre-filter" for Z80: it simply tries to interpret Z80 opcodes and translating them into .BYTE etc directives, so ca65 can assemble it, with all the benefits it can provide, still. At once I had some discussion with Uz (cc65 creator) to have Z80 support in Ca65, but my mouth is often bigger than my abilities and/or available spare time to do it myself. Btw, is CP/M stirctly a 8080 based stuff, or is it accepted more or less to use additional opcodes of the Z80? I am not sure though if it's off-topic to talk about CP/M here: it's not a CBM topic too much, but there is connection, like with this :) https://plus.google.com/photos/104552937405337882900/albums/posts/5672923435555138738 :) or the C128 for example. > would probably be a hardware challenge too. In later editions of the > Commodore 64 Programmer's Reference Guide, the pages about the CP/M > cartridge were made blank. Someone should really donate me an SFX Sound Expander anyway :) Or my project to build one should be done myself, hmm. Öitä. > > Marko > > Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2011-11-27 23:00:08
Archive generated by hypermail 2.2.0.