Re: SFX Expander programming and VICE

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 list